1. The Field of the Invention
The present invention relates to electronic negotiation, and more specifically, to electronically negotiating application layer properties.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., packetizing, routing, flow control). The Open System Interconnect (“OSI”) model is an example of a networking framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into seven distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer. The application layer, the upper most layer, is responsible for supporting applications and end-user processes. Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer protocol is the Transmission Control Protocol (“TCP”).
Often, when two computing systems desire to communicate with each other, the two computing systems must identify mutually supported communication options that can be used to facilitate the exchange of electronic messages. To identify mutually supported communication options, each computing system typically sends its supported communication options, such as, for example, version numbers, cipher settings, and protocols, to the other computing system. From the exchanged communication options, an intersection of mutually supported communication options can be identified. The communication options included in the identified intersection are then used to configure communication between the two computing systems. For example, if a first computing system indicates support for SSL version 2 and SSL version 3 and a second computing system indicates support for only SSL version 2, SSL version 2 can be viewed as an intersection of mutually supported communication options. SSL version 2 can then be used when transferring electronic messages between the first and second computing systems.
Unfortunately, some computer systems may not indicate all of the communication options they support. Thus, identifying an intersection of mutually supported communication options may not be possible. For example, it may be that the second computing system supports SSL version 2 but does not indicate support for SSL version 2 to the first computing system. Thus, electronic messages are not transferred using SSL version 2 even though both the first and second computing systems support SSL version 2. Further, an identified intersection of mutually supported communication options may not always include the most appropriate communication options. For example, it may be that the second computing system supports both SSL version 2 and SSL version 3 (often considered more secure than SSL version 2) but does not indicate SSL version 3 support to the first computing system. Thus, other computing systems that desire to transfer sensitive personal or financial data to the second computing system may refrain from doing so (or may use the less secure SSL version 2) because it appears that the second computing system does not support SSL version 3.
Further, there are limited, if any, mechanisms, for the other computing systems to negotiate (as opposed to simply identifying an intersection of) communication options that are to be used. Thus, these other computing systems may have no way to cause the second computing system to reveal that it supports SSL version 3. Additionally, identified intersections of communication options are frequently identified at lower layers in a protocol stack. Many application layer processes (in part due to the configuration of protocol stacks) lack the ability to alter functionality at lower layers of a protocol stack. Thus, if an application layer process requests communication options that differ from those identified by lower layers, the application layer process is typically not able to utilize the requested communication options.
For example, an application designer may design an application layer process to utilize particular communication options. However, when a computing system including the application layer process exchanges communication options with another computing system the particular communication options are not identified. Thus, in contradiction to the application designer's desired functionality, the application layer process is prevented from utilizing the particular communications options. This is unfortunate as the application designer is often in a better position to decide the desired communication options for an application layer process.
Further, identified intersections of communication options are typically identified from among communication options exchanged by only two computing systems. Thus, to configure communication options between three or more computing systems multiple intersections may need to be identified. Each intersection can result in different communication options that are in turn used to configure communication between different computing systems. When transferring an electronic message through a computing system, the electronic message may need to be converted for compatibility with different configured communication options. For example, a routing computing system may receive an electronic message, which is securely transferred using SSL version 2, from a sending computing system. To compatibly transfer the electronic message to a receiving computing system, the routing computing device may need to convert the electronic message for secure transfer using SSL version 3. Converting between different communication options is inefficient and consumes resources that would otherwise be available to other components of the routing computing system.
Therefore systems, methods, computer program products, and data structures for electronically negotiating application layer properties would be advantageous.